Can some maintainer help to review this PR?

It makes the semantics of as and ts more consistent, with a slight performance loss, yet I believe this trade-off is worthwhile. @MaxGraey WDYT?

I'm not sure. I think AssemblyScript provides much more obvious and logical approach. JavaScript has historically had a lot of quirks, and I think this is one of them. Also, it's breaking change

@MaxGraey In my opinion, the assemblyscript need to follow typescript/javascript design

1. It's a javascript spec compliance. ECMAScript §13.3.6.1 mandates callee evaluation before arguments. AS claims to be a TS subset — deviating here silently produces wrong results.

2. It's not a quirk, evaluating the callee before arguments is the common convention across major languages, aligning with most programmers' mental model.

   Python — guaranteed left-to-right evaluation:

   def log_a(x):
       global value
       value = 100
   
   def log_b(x):
       global value
       value = 200
   
   value = 0
   fn = log_a
   
   def foo(x):
       global fn
       fn = log_b
       return x
   
   fn(foo(42))
   print(f"value = {value}")  # → 100

   Java — same behavior:

    import java.util.function.IntConsumer;
   
   public class EvalOrderTest {
       static int value = 0;
       static IntConsumer fn;
   
       static void logA(int x) { value = 100; }
       static void logB(int x) { value = 200; }
   
       static int foo(int x) {
           fn = EvalOrderTest::logB;
           return x;
       }
   
       public static void main(String[] args) {
           fn = EvalOrderTest::logA;
           fn.accept(foo(42));
           System.out.println("value = " + value);  // → 100
       }
   }

   Both Python and Java guarantee value = 100 — AS is the outlier among languages that claim defined semantics.

3. Negligible perf cost. The allTrivial fast path skips the extra temp local when no side effects exist, which is the common case.

4. Not a real breaking change. Code relying on the wrong order is already buggy. Fixing correctness doesn't break correct programs.

Oh, now I see. Сallee should be saved before args run. Otherwise, side effects can swap the function under your feet, which is pretty footgun-y.

It will be great to add smoke test for compiler which check correct order in output.

Something like:

function origCallback(x: i32): void {
  trace(`called origCallback with ${x}`);
}

function replacedCallback(x: i32): void {
  trace(`called replacedCallback with ${x}`);
}

let cb = origCallback;

function newCallback(): i32 {
  trace("inside newCallback, replacing cb");
  cb = replacedCallback;
  return 42;
}

trace("before call");
cb(newCallback());
trace("after call");